EIGRP for IP by Alvaro Retana Russ White Don Slice & Russ White & Don Slice

EIGRP for IP by Alvaro Retana Russ White Don Slice & Russ White & Don Slice

Author:Alvaro Retana,Russ White,Don Slice & Russ White & Don Slice
Language: eng
Format: epub
Publisher: Pearson Education Limited (US titles)
Published: 2000-03-16T05:00:00+00:00


Frame Relay and Bandwidth Statements

One potential problem EIGRP may face with frame relay links is that the rate at which the router connects to the link is not necessarily the rate at which EIGRP can reliably deliver packets. In Figure 3.15, for example, the access rate for the connection to the frame relay network

Figure 3.15. A hub-and-spoke network

on router A is T1 (1.544Mbps), but the access rate from router B is 64Kbps. Additionally, frame relay service providers may provide a CIR (committed information rate), for each connection, defining the data rate the provider will guarantee to deliver across the link. Any traffic that exceeds the CIR value is subject to being discarded in the frame relay network. In Figure 3.15, the CIR for our example link is 32Kbps.

Why should EIGRP care about the available delivery rate on the link? If it is sending updates, queries, or replies across a link, EIGRP should reasonably expect that the traffic it is sending will be delivered to the remote end. Because routers normally try to send data on a link as quickly as the physical link will accept it, EIGRP’s packets would leave router A at 1.544Mbps into the frame relay cloud. Even if the traffic made it across the frame relay network at this rate, it can be delivered to router B only at 64Kbps. However, because the CIR is only half that rate, much of the traffic would probably be discarded in the cloud, anyway!

As EIGRP is most likely going to be sending large amounts of updates, queries, or replies during times of network instability, the worst thing to happen would be if the packets used to converge on the network changes are themselves being dropped. Regaining network stability would definitely be in jeopardy.

In order to avoid this problem, EIGRP uses the defined bandwidth value to determine how quickly it could send EIGRP traffic to its neighbors. The bandwidth value on the interface is now used to define the pacing interval EIGRP will use to put gaps between packets to ensure that it will not overwhelm the intervening network. By default, EIGRP will not use more than 50 percent of the defined bandwidth for reliable packets (updates, queries, and replies). This percentage can be changed on a per interface basis, using the command ip eigrp <AS> bandwidth-percentage <percent>. Later in this section, we will explain why it may be desirable to change the bandwidth percentage.

For this pacing improvement to work, however, you must manually define the bandwidth values on each frame relay interface/subinterface. Although it seems to be laborious, it is necessary to make EIGRP behave correctly on frame relay networks. The results are worth the effort! In most of the following discussion, we refer to frame relay networks, but the principles also apply to other technologies, such as SMDS (switched multimegabit data service), ATM (asynchronous transfer mode), and ISDN/PRI (integrated services digital network/primary rate interface).

Frame relay networks have primarily two scenarios, and each has its own requirements for defining the bandwidth.



Download



Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.